Replication method

ABSTRACT

A directory system for performing replication of directory data, in which a directory server on the consumer side can reconstruct replica data using a backup kept at any point in time. Information  10   c  for specifying the entry changed for the last time by replication performed by replication service  10 ′ is recorded into the replica data  9   c  managed by the directory server on the consumer side. Based on this information, the replication service  10 ′ can know the entry on which next replication is to be performed. Thus, the replication service  10 ′ can recognize the difference between the master data  9   s  managed by the directory server on the supplier side and the replica data  9   c , and can perform replication on this difference when only the replica data  9   c  is reconstructed using the backup.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention relates to a technique which can improveoperability in managing a replica of directory data.

[0003] 2. Related Art Statement

[0004] It is now often the case that, in an OA (Office Automation)environment, such as an in-house information system, in which a numberof independent systems such as a mail system, a file sharing system etc.are intermixed, a user has plural items of user identifying informationsuch as mail addresses, login names, passwords, etc. Accordingly, withincrease or decrease of users, an administrator must add or eliminateeach item of the user identifying information used in respectivesystems, which imposes a heavier burden on the management.

[0005] Thus, it is desired to lighten the administrator's managementburden by employing a directory system which can perform directoryservices for administering items of user identifying information used ina plurality of systems and items of information existing on apparatusesand resources in a unified manner. By applying such a directory system,it will be possible to search for information desired by a user andprovide it.

[0006] Heretofore, such a thus-described in-house information system hasbeen constructed separately for each small department. However, in-houseinformation systems different for respective departments can notsmoothly perform procedures relating to movements of personnel or mailexchanges between departments. Thus, construction of a large-scale widerarea in-house information system unified for the whole company israpidly advanced.

[0007] As such a large-scale wider area in-house information systemdevelops, it is desired for a directory system to maintain accessperformance irrespective of the scale of the system. In addition, fromthe viewpoint of reliability, multiplexing of the service is requiredfor preventing interruption of the entire service caused by theoccurrence of a problem in a single place.

[0008] To reply to such a request, it is effective to arrange replicasof directory data in a plurality of places. Hereinafter, a replica ofdirectory data is referred to as “replica data”, and replicatingdirectory data is referred to as “replication”.

[0009] As a standard relating to replication in directory service, therecan be mentioned X.500 recommended by CCITT. In X.500, a client/servertype distributed system architecture is provided for directory service,and DAP (Directory Access Protocol) is provided as a protocol foraccessing a directory among clients and servers.

[0010] Concerning replication, a directory server that manages originaldirectory data (master data) of a replication source and supplydirectory data to be replicated is defined as a supplier side, and adirectory server that manages replica data and receives the directorydata to be replicated is defined as a consumer side. Further, DSP(Directory Information Shadowing Protocol) is provided as a replicationprotocol between a directory server on the supplier side and a directoryserver on the consumer side.

[0011] As an operation model, there are a “push” model in whichreplication is started up by a directory server on the supplier side,and a “pull” model in which replication is started up when a directoryserver on the consumer side requests data.

[0012] On the other hand, IETF (Internet Engineering Task Force)employed LDAP (Light Weight Directory Access Protocol) (RFC1777) whichoperates on a TCP/IP stack as a standard protocol for directory access.

[0013] Now, conventional replication using LDAP as a replicationprotocol will be described.

[0014] In the following, a directory server that manages master data iscalled a “supplier directory server”, and a directory server thatmanages replica data is called a “consumer directory server”. Further, aserver that propagates a modify operation performed in the supplierdirectory server to a consumer directory server is called “replicationserver”.

[0015] As a directory access request in LDAP, there are a reference typedirectory access request that does not change directory data and anupdate type directory access request that makes change in directoryaccess data. As the reference type directory access request, thereexists only a search request. As the update type directory accessrequest, there are an entry addition request, an entry deletion request,and an RDN change request.

[0016] When the supplier directory server succeeds in a modify operationin accordance with an update type directory access request, it adds atime stamp to replication log of this modify operation, and stores it asa replication record in a replication log file. Such time stamps areused for identifying the order in which replication records were stored,i.e., the order in which modify operations according to respectiveupdate type directory access requests were performed.

[0017] In the conventional replication server, when replication is to beperformed, replication records are first acquired from the replicationlog file in such an order that time stamps are not decreased. Then,based on the acquired replication records, update type directory accessrequests (LDAP access requests) are prepared, and the prepared LDAPaccess requests are issued to a consumer directory server.

[0018] As a result, that consumer directory server can perform modifyoperations in accordance with the same update type directory accessrequests in the same order as the update type directory access requestswhich caused the changes performed in the supplier directory server.

[0019] However, since, as described above, the replication server onlypropagates modify operations, an administrator of the consumer directoryserver must prepare a replica of the master data as replica data beforethe replication is started.

[0020] Operation of the replication is a “push” model when thereplication server starts replication in accordance with output ofreplication records by the supplier directory server, and a “pull” modelwhen replication is started in accordance with a state of the consumerdirectory server.

[0021] In the present description, replication in a “push” model isassumed.

[0022] Further, a time stamp is a numerical value based on a time pointwhen the supplier directory server receives an update type directoryaccess request, on a time point of a modify operation, or on a timepoint when a replication record is stored into the replication log file.Time stamps should be arranged in ascending order of performing modifyoperations.

[0023]FIG. 3 shows a replication sequence performed by the conventionalreplication server.

[0024] As shown in FIG. 3, the conventional replication server reads outa replication record (31) from the replication log file.

[0025] Successively, the replication server issues a bind request (32)to a consumer directory server, and receives a response (33) to it,which establishes a connection with the consumer directory server.

[0026] Successively, the replication server prepares an LDAP accessrequest (34) based on the replication record (31) read out. In thefollowing description, such an LDAP access request is called a“replication request”.

[0027] Then, the replication server issues the prepared replicationrequest (34) to the consumer directory server, and receives a response(35) to it. When a return code included in this response (35) is“LDAP_SUCCESS” indicating success of the replication, the replicationserver records a replication status (37). Here, the time stamp of thesuccessful replication record is stored into a replication status file.

[0028] The replication server always reads out the replication recordhaving the oldest time stamp among replication records having timestamps subsequent to one stored in the replication status file, so thatit can perform replication in the same order as the modify operationswere performed by the supplier directory server.

[0029] Thereafter, the replication server issues an unbind request (38)to cut off the connection with the consumer directory server.

[0030] According to the above-described sequence, it is possible thatthe consumer directory server performs the same modify operations in thesame order as ones performed in the supplier directory server. Thus, thereplica data managed by the consumer directory server can be madeidentical to the master data managed by the supplier directory server.

[0031] As an example of a server program for implementing such asequence as described above, a replication service program “slurpd”developed by Michigan University is provided free on the Internet.

SUMMARY OF THE INVENTION

[0032] In the above-described conventional technique, when replica datamanaged by a consumer directory server has been lost owing to, forexample, physical damage of a magnetic disk, or the like, a copy of themaster data managed by the supplier directory server located in ageographically distant place must be obtained to reconstruct the replicadata. Thus, it requires the effort of an administrator, and takes timefor recovery.

[0033] Even if a backup of the replica data has been kept, it isimpossible to reconstruct the replica data using that backup data. Thatis, since it is unknown that up to which replication record the backupdata are reflecting replication records, the replication server can notrestart the replication for the backup data. In that case, in thereplication server, the time stamp stored in the replication status fileis a value at the time damage occurred, and it does not necessarilycorrespond to the backup data.

[0034] Thus, in the conventional technique, the replication server cannot recognize the difference between the master data and backup data,and accordingly, it can not perform replication for the backup data atthe time of reconstruction of the replica data.

[0035] Further, in the conventional technique, in a case wherereplication ends abnormally owing to such a problem as power supplyinterruption between issuance of a replication request and receipt of aresponse to it, the replication server can not receive the response fromthe consumer directory server. As a result, a time stamp of areplication record in the last successful replication is not recorded.

[0036] For this reason, after recovery from a problem, to restart thereplication, the replication server issues an identical replicationrequest to the one issued in the replication of the last session.Accordingly, if the consumer directory server has succeeded in themodify operation according to the replication request issued in thereplication of the last session, the same replication request is issuedrepeatedly, and the modify operation according to this replicationrequest results in failure. In such a case, the replication server endsabnormally, and the administrator must perform a recovery operationmanually.

[0037] Thus, a first object of the present invention is to realizereplication which may be restarted for a backup of replica data even ifthat replica data has been lost, and improved its operability.

[0038] Further, a second object of the present invention is to realizereplication which may be restarted normally after recovery from thetrouble and improved its operability, even if replication is interruptedowing to an unexpected problem at any time point.

[0039] To attain the above-mentioned first object, the present inventionprovides, as its first aspect, a replication tool for keeping contentsof master data and contents of replica data in a directory system, inwhich, a first directory server manages the master data of directorydata and records and holds replication log of operations in changing themaster data; one or more second directory servers each manages theirreplica data as a replica of the master data; and the first directoryserver and the one or more second directory servers are connected atleast through a network, the replication tool being installed in one(hereinafter, referred to as “replication server”) of the firstdirectory server and another server connected to the network, wherein:

[0040] the replication server comprises:

[0041] replication log acquiring means for acquiring a replication logwhich becomes an object of processing out of the replication logrecorded and held by the first directory server;

[0042] replication request issuing means for issuing a directory accessrequest (hereinafter, referred to as “replication request”) thatrequests performing, on the replica data, the same operations asoperations corresponding to the history operation acquired by thereplication log acquiring means, to the second directory server; and

[0043] identifying information recording means for recording anidentifying information for specifying the replication log correspondingto the operations performed by the second directory server, into thereplica data managed by the second directory server, when the operationperformed in accordance with the replication request issued by thereplication request issuing means are successful, and

[0044] the replication log acquiring means refers to the identifyinginformation recorded in the replica data managed by the second directoryserver to decide a replication log to be acquired.

[0045] According to the first aspect of the present invention, theidentifying information recorded in the replica data managed by thesecond directory server specifies the entry changed for the last time bythe operation of the second directory server in accordance with thereplication request (the entry changed by replication for the lasttime). Thus, by referring to this identifying information, thereplication server can know the entry on which next replication is to beperformed, and accordingly, can recognize difference of the master datamanaged by the first directory server with the replica data managed bythe second directory server.

[0046] Thus, by keeping a backup of the replica data including thisidentifying information, it is possible for the second directory serverto reconstruct the replica data using the backup, without acquiring allthe entries in the master data, even when the replica data has been lostowing to, for example, physical damage of a recording medium, and thusimprove its operability.

[0047] Namely, according to first aspect of the invention, even when thereplica data has been lost, it is possible to restart replication forthe backup of the replica data, thus realizing the replication withimproved operability.

[0048] In a case where, in the first aspect of the invention, thereplication log includes order information indicating the order ofexecution of corresponding operations, the identifying informationrecording means may employ the order information as the identifyinginformation to be recorded. Also, the replication log acquiring meansmay decide, as the replication log to be acquired, a replication logincluding order information which indicate the earliest execution orderout of replication log including order information indicating anexecution order later than the execution order indicated by the orderinformation included in the identifying information referred to.

[0049] Further, the present invention provides, as a second aspect, areplication tool, characterized in that, in the first aspect of thepresent invention, the replication log acquiring means issues adirectory access request that requests performing an operation ofsearching the identifying information, to the second directory server,so as to refer to the identifying information recorded in the replicadata managed by the second directory server.

[0050] According to the second aspect, the identifying information canbe treated as contents set in one entry within the replica data. Thus,the second directory server can perform the operation of searching theidentifying information similar to the search operation in accordancewith above-described reference type directory access request, andoperations of the second directory server may be similar to theconventional one.

[0051] Further, the present invention provides, as a third aspect, areplication tool characterized in that, in one of the first and secondaspects of the invention, the identifying information recording meansissues a directory access request that requests performing an operationof recording the identifying information, to the second directoryserver, so as to record the identifying information into the replicadata managed by the second directory server.

[0052] According to the third aspect, the identifying information can betreated as contents set in one entry within the replica data. Thus, thesecond directory server may perform an operation of recording theidentifying information similar to a modify operation in accordance withthe reference type directory access request, and operation of the seconddirectory server may be similar to the conventional one.

[0053] Further, the present invention provides, as a fourth aspect, areplication tool characterized in that, in one of the first throughthird aspects of the invention, the replication server furthercomprises:

[0054] an error judgment means that operates in such a manner that, evenwhen the operations performed by the second directory server inaccordance with the replication request issued by the replicationrequest issuing means result in failure, the error judgment means judgesthe failure as success if the failure is caused by issuing the samereplication request as the replication request successively more thantwice, and the second servers previously received the same replicationrequest as the replication request.

[0055] For example, in a case where a problem happens after success ofthe operation performed by the second directory server in accordancewith a replication request and the replication is interrupted, recordingof the identifying information results in failure. Then, after recoveryfrom the problem, and when the replication server restarts thereplication, it refers to unchanged false identifying information toissue a replication request. Also, an operation performed by the seconddirectory server in accordance with this replication request results infailure.

[0056] However, according to the fourth aspect of the present invention,the replication server may be able to evaluate such an operation assuccess, and it is possible to maintain the replica data correctly andto continue the replication

[0057] Further, the present invention provides, as a fifth aspect, areplication tool characterized in that, in one of the first and secondaspects of the invention, when said second directory server is adirectory server that can perform a predefined specific operation inaccordance with contents set into a predefined specific field within adirectory access request received, said identifying informationrecording means sets, into said specific field of said replicationrequest issued by said replication request issuing means, informationnecessary for said second directory server to perform a specificoperation of recording said identifying information, so that saididentifying information is recorded into the replica data managed bysaid second directory server.

[0058] According to the fifth aspect, in addition to the effect of thethird aspect, it is possible that said second directory server canperform an operation of recording said identifying information in oneissue of a replication request. Thus, except for a replication request,the replication server need not issue a directory access request forrequesting an operation of recording said identifying information, whichsuppress increase of network traffic.

[0059] Further, to attain the above-described second object, it isnecessary to solve the following problem. Namely, in a case where aproblem happens before the replication server knows if an operationperformed by said second directory server in accordance with an issuedreplication request has been successful or not, and the replication isinterrupted, the replication may not be restarted normally afterrecovery from the problem.

[0060] Accordingly, to solve the problem, in the present invention, inone of the third and fifth aspects of the invention, said seconddirectory server performs an operation according to said replicationrequest and an operation of recording said identifying information, inthe same single transaction.

[0061] As a result, consistency of the replica data with the identifyinginformation can be assured, and the above-described second object isattained.

BRIEF DESCRIPTION OF THE DRAWINGS

[0062]FIG. 1 is an explanatory view showing a functional configurationof replication service according to a first embodiment;

[0063]FIG. 2 is an explanatory view showing a system configuration of adirectory system according to the first embodiment;

[0064]FIG. 3 is an explanatory view showing the sequence of theconventional replication service;

[0065]FIG. 4 is an explanatory view showing a sequence of replicationservice according to the first and second embodiments;

[0066]FIG. 5 is an explanatory view showing error recovery processing inthe first embodiment;

[0067]FIG. 6 is an explanatory view showing information to be stored ina replication definition file;

[0068]FIG. 7 is an explanatory view showing information to be stored ina replication log file;

[0069]FIG. 8 is an explanatory view showing information to be set intothe “change contents” within the replication record shown in FIG. 7,when the “modify operation type” within the replication record is“modify”;

[0070]FIG. 9 is an explanatory view showing information to be set intothe change contents within a replication record, when the modifyoperation type within the replication record is “add”;

[0071]FIG. 10 is an explanatory view showing subclasses of an objectclass in the first through third embodiments;

[0072]FIG. 11 is an explanatory view showing a format for a value oflastReplRecord attribute value, which is a replication record identifierin the first through third embodiments;

[0073]FIG. 12 is an explanatory view showing information to be stored ina replication status file 21;

[0074]FIG. 13 is an explanatory view showing LDAP return codes belongingto Group 1;

[0075]FIG. 14 is an explanatory view showing LDAP return code belongingto Group 2;

[0076]FIG. 15 is a flowchart showing a flow of processing by areplication server program in the first embodiment;

[0077]FIG. 16 is a flowchart showing a flow of processing by a changelog acquisition program in the first through third embodiments;

[0078]FIG. 17 is a flowchart showing a flow of processing by an errorjudgment program in the first embodiment;

[0079]FIG. 18 is a flowchart showing a flow of processing by areplication status recording program of the first embodiment;

[0080]FIG. 19 is a flowchart showing a flow of processing by areplication server program of the second embodiment;

[0081]FIG. 20 is an explanatory view showing a notation of an LDAPaccess request defined in LDAP;

[0082]FIG. 21 is an explanatory view showing a notation of Controlsdefined in LDAP;

[0083]FIG. 22 is an explanatory view showing information to be set intoControl field of a replication request in the third embodiment;

[0084]FIG. 23 is an explanatory view showing a sequence of replicationservice according to the third embodiment;

[0085]FIG. 24 is a flowchart showing a flow of partial processing fromreceipt of a replication request to return of response performed by aconsumer directory server program;

[0086]FIG. 25 is a flowchart showing a flow of processing by areplication server program in the third embodiment;

[0087]FIG. 26 is an explanatory view showing a functional configurationof replication service according to the third embodiment;

[0088]FIG. 27 is an explanatory view showing a system configuration of adirectory system according to the third embodiment; and

[0089]FIG. 28 is a flowchart showing a flow of processing by areplication status recording program according to the second embodiment.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0090] Now, embodiments of the present invention will be describedreferring to the drawings.

[0091] To start with, a first embodiment according to the presentinvention will be described.

[0092]FIG. 2 shows a system configuration of a directory systemaccording to the first embodiment. In the figure, the reference numeralis refers to a first directory server, and 1 c to a second directoryserver.

[0093] Similarly to the conventional technique, in the first embodiment,a plurality of directory servers (two servers, i.e. the first directoryserver is and the second directory server 1 c) are provided formaintaining access performance and for improving reliability. The firstdirectory server 1 s is on the supplier side and issues a replicationrequest to the second directory server 1 c on the consumer side whendirectory data (master data) managed by the first directory server isitself is changed, so as to perform replication. By this replication,directory data (replica data) managed by the second directory server 1 cis changed to have the same contents as the master data. Here, in thefirst embodiment, the first directory server is itself operates as areplication server that performs replication.

[0094] Differing from the conventional technique, a backup of thereplica data is kept in the first embodiment. Thus, when the replicadata has been lost due to, for example, damage of a recording medium, itis possible to restart the replication for the backup data, and toreconstruct the replica data using the backup data without acquiring allthe entries in the master data from the first directory server is, thusimproving operability.

[0095] Namely, for entries included in the backup, the second directoryserver 1 c uses the backup to recover the replica data. Only for entrieswhich are not included in the backup, the first directory server isrestarts the replication to recover the replica data.

[0096] To that end, it is necessary that the first directory server isitself recognizes the difference between the master data managed byitself and the replica data (recovered one using the backup) managed bythe directory server 1 c, and perform the replication only for thedifference. However, the conventional technique can not recognize suchdifference.

[0097] Accordingly, in the first embodiment, as will be described below,it is made possible for the first directory server is to recognizeentries in the replica data changed for the last time, so as to make itpossible to recognize the difference between the master data and thereplica data.

[0098] Now, referring to FIG. 2 again, the first directory server 1 scomprises a central processing unit (CPU) 2 s, a memory 3 s, a magneticdisk 4 s, a disk controller 5 s, and a LAN controller 6 s.

[0099] At start-up of the first directory server 1 s, CPU 2 s loads anoperating system (OS) 7 s, a supplier directory server program 8 s formanaging the master data 9 s, and a replication server program 10 forperforming replication, from the magnetic disk 4 s into the memory 3 sthrough the disk controller 5 s.

[0100] The replication server program 10 contains, within itself, achange log acquisition program 11, a request generation program 12, areplication status recording program 15, an error judgment program 13,and a communication control program 14.

[0101] Further, in the magnetic disk 4 s, there exist the replica data 9c managed by the supplier directory server program 8 s, a replicationdefinition file 19, a replication log file 20, and a replication statusfile 21. The replication definition file 19 stores information necessaryfor connecting with the consumer directory server program 8 c. Into thereplication definition file 19, there is stored a replication log of amodify operation as a replication record, when the supplier directoryserver program 8 s changes the master data 9 s. When the replicationserver program 10 succeeds in replication, a record identifierindicating a replication record corresponding to a modify operation thatcaused the replication is stored into the replication status file 21.

[0102] On the other hand, the second directory server 1 c comprises CPU2 c, a memory 3 c, a magnetic disk 4 c, a disk controller 5 c, and a LANcontroller 6 c.

[0103] At start-up of the second directory server 1 c, CPU 2 c loads anoperating system (OS) 7 c, and a consumer directory server program 8 cfor managing the replica data 9 c, from the magnetic disk 4 c onto thememory 3 c through the disk controller 5 c.

[0104] Further, in the magnetic disk 4 c, there exists the replica data9 c managed by the consumer directory server program 8 c.

[0105] The first directory server 1 s and the second directory server 1c are connected with each other through a local area network (LAN) 100,and communicate with each other through the LAN controllers 6 s, 6 c.

[0106] Each of entries in the master data 9 s and the replica data 9 cmay be made to indicate user identifying information, for example. Inthat case, a user can search desired user identifying information byissuing a search request (reference type directory access request) froma terminal (not shown) when using the first directory server 1 s or thesecond directory server 1 c. Further, a user (especially, anadministrator) can change the master data 9 s by issuing an updaterequest (update type directory access request) from the terminal theyare using to the first directory server is. When the master data 9 s ischanged, the replication server program 10 performs replication tochange contents of the replica data 9 c to the same contents.

[0107] The supplier directory server program 8 s and the replicationserver program 10 may be included in one server program. Otherwise, theymay be constructed as independent server programs. In the case of theindependently constructed server programs, these server programs 8 s, 10may exist in the same server, or they may exist in different serversrespectively.

[0108] As shown in FIG. 2, in the first embodiment, the supplierdirectory server program 8 s and the replication server program 10 areindependently-constructed server programs, and both exist in the sameserver (the first directory server is). Further, it is assumed that theconsumer directory server program 8 c exists in another server (thesecond directory server 1 c) different from the server in which twoserver programs 8 s, 10 operate.

[0109] In the following figures, the same reference numerals are used torefer to the same parts.

[0110]FIG. 1 shows a functional configuration of replication serviceaccording to the first embodiment.

[0111] In FIG. 1, supplier directory service 8 s′ and consumer directoryservice 8 c′ are functional blocks realized respectively by the supplierdirectory server program 8 s and the consumer directory server program 8c shown in FIG. 2. The supplier directory service 8 s′ and the consumerdirectory service 8 c′ manage the master data 9 s and the replica data 9c, respectively.

[0112] In particular, in the first embodiment, the replica data 9 cmanaged by the consumer directory service 8 c′ stores a replicationrecord identifier 10 c for specifying the entry in the replica data 9 cchanged by replication for the last time. In fact, the replicationrecord identifier 10 c is set in a predetermined entry as an attributeincluded in that entry in the replica data managed by the consumerdirectory service 8 c′. In detail, it is set as an attribute value oflastReplRecord attribute of an object class described below referring toFIG. 10.

[0113] A change log 20′ corresponds to the replication log file 20 shownin FIG. 2. After a record identifier consisting of a time stamp and arecord number is added to an update request (update type directoryaccess request) that caused a modify operation by the supplier directoryservice 8 s′, the change log 20′ stores that update request asreplication record. Each of time stamps included in the change log 20′is a number based on a time point when the supplier directory service 8s′ received an update type directory access request, performed a modifyoperation, or stored a replication record in the change log 20′. Thetime stamps should be arranged in an ascending order of performingmodify operations. Further, a record number is a value that isincremented by one at each modify operation.

[0114] On the other hand, replication service 10′ is a functional blockrealized by the replication server program 10 shown in FIG. 2. Thereplication service 10′ contains, internally, five functional blocks,i.e., a change log acquisition part 11′, a replication status recordingpart 15′, a request generation part 12′, an error judgment part 13′, anda communication control part 14′. These five functional blocks 11′-15′are realized respectively by the change log acquisition program 11, thereplication status recording program 15, the request generation program12, the error judgment program 13, and the communication control program14, as shown in FIG. 2.

[0115] In the following, these five functional blocks 11′-15′ will bedescribed.

[0116] The change log acquisition part 11′ acquires a replication recordfrom the change log 20′, based on the replication record identifier 10 cin the replica data 9 c. To specify the entry in the replica data 9 cchanged by replication for the last time, the replication recordidentifier 10 c specifies the replication record corresponding to themodify operation performed when the same entry as the mentioned entrywas changed in the master data 9 s. The replication record identifier 10c includes time stamp and record number of the replication record inquestion. Replication is realized by performing, in the same entry inthe replica data 9 c as a changed entry in the master data 9 s, the samemodify operation as the one performed when the entry in the master data9 s was changed. Thus, to specify the replication record correspondingto the modify operation performed when the entry in the master data 9 swas changed is equivalent to specifying the entry in the replica data 9c changed by the same modify operation as the mentioned modifyoperation.

[0117] Accordingly, from the change log 20′, the change log acquisitionpart 11′ searches and reads out replication records having later timestamps and greater record numbers than the time stamp and the recordnumber included in the replication record identifier 10 c. The changelog acquisition part 11′ reads out such records in ascending order oftime stamps and record numbers. As a result, the replication service 10′can perform replications in the same order as the modify operationsperformed by the supplier directory service 8 s′.

[0118] The request generation part 12′ generates a replication requestbased on the replication record read out by the change log acquisitionpart 11′.

[0119] The communication control part 14′ issues the replication requestgenerated by the request generation part 12′ to the consumer directoryservice 8 c′, and receives corresponding response.

[0120] The replication status recording part 15′ changes the replicationrecord identifier 10 c held by the consumer directory service 8 c′ so asto indicate the entry in the replica data 9 c changed for the last timeby replication. Namely, the replication status recording part 15′changes the replication record identifier 10 c to include the time stampand the record number in the replication record that was the base of theissued replication request.

[0121] The error judgment part 13′ detects a case where, although anentry in the replica data has been changed owing to an already issuedreplication request, change of the replication identifier 10 has failed,and the replication has resulted in failure, and performs error recoveryprocessing.

[0122]FIG. 10 shows directory server class and serverApplicationProcessclass out of object classes to which entries of the directory databelong.

[0123] These object classes are expressed using ASN.1 (Abstract SyntaxNotation One) prescribed as ISO8824.

[0124] That directoryServer class is a subclass defined optionally as asubclass of serverApplicationProcess class, and serverApplicationProcessclass is a subclass defined optionally as a subclass of dSA(directorySystemAgent) prescribed by X.521.

[0125] In the first embodiment, directoryServer has an optionallydefined attribute, lastReplRecord attribute 101. This lastReplRecordattribute 101 is an attribute that exists only when a directory serverprogram is on the consumer side, and denotes the replication recordidentifier 10 c. Further, serverApplicationProcess class is made to haveoptionally defined attributes, ipAddress and hostName, and theseattributes denote a directory server on the consumer side.

[0126]FIG. 11 shows a format for an attribute value of lastReplRecordattribute.

[0127] The attribute value 110 of the lastReplRecord attribute is acharacter string, in which uppercase letters and lowercase letters aredistinguished from each other i.e. a case dependent character string.The replication server program 10 prepares the attribute value 110 bysetting a host name (69 in FIG. 6) of the supplier directory server 1 sstored in the replication definition file 19, and a record number (72 inFIG. 7) and time stamp (71 in FIG. 7) of the last-stored replicationrecord (70 in FIG. 7) in the replication log file 20, into a host name111, a record number 112 and a time stamp 113 of the lastReplRecordattribute value 110, respectively.

[0128] Here, the host name is a DNS (Domain Name Service) name, and aDNS server transforms it into an Internet address (IP address) which canuniquely identify an information processing apparatus on the Internet.

[0129] Stored contents of the replication definition file 19 and of thereplication log file 20 will be described later referring to FIGS. 6 and7.

[0130]FIG. 4 shows a sequence of the replication service according tothe first embodiment.

[0131] As shown in FIG. 4, the replication server program 10 issues abind request (401) to the consumer directory server program 8 c first,and receives a response (402) corresponding to it, to establishconnection with the consumer directory server program 8 c.

[0132] Successively, the replication server program 10 issues alastReplRecord search request (403) to the consumer directory serverprogram 8 c for requesting search of an attribute value of thelastReplRecord attribute, and receives a response (404) including thevalue of lastReplRecord attribute. From the value of the lastReplRecordattribute included in this response (404), the replication serverprogram 10 can obtain the replication record identifier 10 c in thereplica data 9 c managed by the consumer directory server program 8 c.Thus, the replication server program 10 can obtain the time stamp andrecord number of the replication record for specifying the entry changedfor the last time by the replication performed in the last session.

[0133] Next, the replication server program 10 acquires the time stampand the record number included in the value 110 of the lastReplRecordattribute for performing the replication in time series for entries onwhich the replication has not been performed. Based on these acquiredvalues, the replication server program 10 reads out (405) a replicationrecord.

[0134] In detail, from the replication log file 20, the replicationserver program 10 reads out the replication record 414 having the lasttime stamp and smallest record number out of replication records havinga time stamp later than the acquired time stamp “80000000” and a recordnumber greater than the acquired record number “456”.

[0135] Then, based on the replication record 414 read out, thereplication server program generates a replication request.

[0136] Here, in the first embodiment, LDAP is employed as a protocol foraccessing a directory, and the generated replication request becomes anLDAP access request. Further, it is assumed that a modify operationknown from the replication record 414 is an addition operation of theentry A, and accordingly, the generated LDAP access request is an entryA addition request (406).

[0137] Successively, the replication server program 10 issues thegenerated entry A addition request (406) to the consumer directoryserver program 8 c. On receiving the entry A addition request (406), theconsumer directory server program 8 c performs addition (407) of theentry A and returns a response (408) indicating the execution result.

[0138] The replication server program 10 receives the response (408)from the consumer directory server program. When a return code includedin this response (408) is “LDAP_SUCCESS” indicating success of thereplication, the replication server program 10 stores the time stamp“80000001” and record number “457” of the replication record 414 intothe replication status file 21, as a record identifier indicating thereplication record 414 (409).

[0139] According to the above-described sequence, the entry A additionoperation performed in the supplier directory server program 8 s ispropagated to the consumer directory server program 8 c.

[0140] Further, in the first embodiment, after the success of the modifyoperation by the consumer directory server program 8 c in accordancewith the replication request, the replication server program 10 recordsthe time stamp “80000001” and record number “457” of the replicationrecord 414 on the consumer directory server program 8 c.

[0141] In detail, it sets the host name of the first directory server ison which the supplier directory server program 8 s operates, and thetime stamp and record number of the replication record 414 into the hostname 111, the time stamp 113 and the record number 112 of thelastReplRecord attribute value 110 shown in FIG. 11, respectively, togenerate a new value of the lastReplRecord attribute. Then, thereplication server program 8 s issues a lastReplRecord update request(410) for requesting change of the value of the lastReplRecord attributevalue. When the value of the lastReplRecord attribute is changed (411)and a response to the lastReplRecord update request (410) is received,the replication server program 10 issues an unbind request (413) to cutoff the connection with the consumer directory server program 8 c.

[0142] According to the above-described sequence, the replica data 9 cmanaged by the consumer directory server program 8 c has thelastReplRecord attribute value indicating the replication record forspecifying the last entry changed for the last time by replication, asthe replication record identifier 10 c.

[0143] As described above, the replication server program 10 searchesthe lastReplRecord attribute value before issuing the replicationrequest, so as to know the replication record identifier 10 c forspecifying the entry changed for the last time by the replicationperformed by the last session. As a result, the replication serverprogram 10 can know the replication record that becomes a base for thenext replication.

[0144] Similarly, for a backup of the replica data 9 s at an arbitrarytime, the replication server program 10 can make the contents of themaster data 9 s and the contents of the replica data 9 c the same, byacquiring only the replication records for specifying untreated entriesthat are the different from the master data 9 s managed by the supplierdirectory server program 8 s, and by performing the replication.

[0145] Thus, according to the first embodiment, by keeping a backup ofthe replica data 9 c including the lastReplRecord attribute value, it ispossible to restart the replication for the backup data even when thereplica data 9 c has been lost owing to, for example, physical damage ofa magnetic disk 4 c. Accordingly, it is possible for the seconddirectory server 1 c to reconstruct the replica data 9 c using thebackup without acquiring all the entries in the master data 9 s from thefirst directory server is, thus improving operability.

[0146] In the first embodiment, the replication server program 10 issuesone replication request and one lastReplRecord update request in everysession, and completes the session. However, it is possible that, in onesession, replication requests are issued a plurality of times and then,lastReplRecord update requests are issued a plurality of times,alternately. In that case too, the same effect is obtained in thepresent invention.

[0147] In the first embodiment, a replication request and alastReplRecord update request are issued as separate requests. Thus,between a modify operation in accordance with the replication requestand a modify operation in accordance with a lastReplRecord updaterequest, the value of the lastReplRecord attribute does not indicate acorrect replication record identifier 10 c.

[0148] Accordingly, in a case where a problem arises during that period,error recovery processing is required, and will be described in thefollowing.

[0149]FIG. 5 shows an error recovery processing to be performed in thefollowing case. Namely, a modify operation in accordance with an entry Aaddition request (501) is successfully performed by the consumerdirectory server program 8 c. Then, the replication server program 10records a replication status (502). Thereafter, a problem such as powersupply interruption occurs in the second directory server 1 c, and theconsumer directory server program 8 c abnormally ends without performinga modify operation on the lastReplRecord attribute value (503).

[0150] In that case, as the consumer directory server program 8 c hasnot performed the modify operation on the lstReplRecord attribute value(503), the replication server program 10 will receive a response (504)including the same value of the lastReplRecord attribute as the oneacquired in the replication in the last session, when it searches thelastReplRecord attribute value after the restart. Then, the replicationserver program 10 again reads out the replication record A (505) readout from the replication log file 20 in the last session, and againissues the same entry A addition request (506) as the one (501) issuedin the last session.

[0151] Here, if the modify operation according to the entry A additionrequest (501) was performed successfully before the restart, then, intrying to perform a modify operation according to the entry additionrequest (506), the consumer directory server program 8 c fails in thatoperation since the entry A exists already. Thus, a return code includedin the response (507) to that request becomes “LDAP_ALREADY_EXISTS”.Here, “LDAP_ALREADY_EXISTS” is a return code generated when the sameentry addition operation is repeated.

[0152] Accordingly, in the first embodiment, when a return code includedin a response to a replication request is “LDAP_ALREADY_EXISTS”, thereplication server program 10 judges if the replication request inquestion (here, the entry A addition request (506)) is the same as thereplication request issued in the last session. When they are the same,the replication server program 10 judges that the consumer directoryserver program 8 c has been successful in the modify operation accordingto that replication request, and then issues a lastReplRecord updaterequest.

[0153] Further, when the time stamp and record number of the replicationrecord A (505) are the same respectively as the time stamp and recordnumber stored in the replication status file 21, the replication serverprogram 10 can judge that the replication request issued in the lastsession and the replication request issued in the current session arethe same.

[0154] According to the above-described error recovery processing, it ispossible to keep replica data 9 c correct and to continue thereplication, even if a change of the lastReplRecord attribute value cannot be performed.

[0155] Now, items of information stored respectively in the replicationdefinition file 19, the replication log file 20, and the replicationstatus file 21 will be described.

[0156] First, FIG. 6 shows information to be stored in the replicationdefinition file 19. These items of information are used when thereplication server program 10 establishes connection with the consumerdirectory server program 8 c.

[0157] As shown in FIG. 6, the replication definition file 19 stores ahost name 61 of the consumer directory server 1 c in which the consumerdirectory sever program 8 c operates, a port number 62, a bind method63, bind DN 64 and password which are authentication information used atthe time of binding, a directory server object DN 67, change logposition 68, and a host name 69 of the supplier directory server is onwhich the supplier directory server program 8 s operates.

[0158] Further, the directory server object DN 67 is used fordesignating a replication record identifier 10 c (i.e., an entry inwhich a lastReplRecord attribute value is set), and the change logposition 68 is an absolute path used by the supplier directory serverprogram 8 s for storing a replication record into the replication logfile 20.

[0159] In the first embodiment, as a method of authentication performedat the time of binding, there is employed a method where it is judged ifthe bind DN 64 and password 65 sent by the replication server program 10at the time of binding coincide respectively with a bind DN and passwordregistered in advance by an administrator of the consumer directoryserver program 8 c. When they coincide, the consumer directory serverprogram 8 c allows the replication server program 10 to establishconnection.

[0160] An administrator of the replication server program 10 preparesthe replication definition file 19 prior to start-up of the replicationserver program 10.

[0161]FIG. 7 shows information stored in the replication log file 20.

[0162] As shown in FIG. 7, for each replication record 70, thereplication log file 20 stores the above-described time stamp 71 andrecord number 72, a modify operation object DN 73, a modify operationtype 74, change contents 75, a new RDN 76 as RDN after change, attributevalue deletion instruction flag 77, and a new upper RDN 78 as a parentRDN.

[0163] In the first embodiment, the time stamp 71 is a character stringindicating a number of seconds that have passed from Jan. 1, 1970.Further, the modify operation type 74 indicates the type of modifyoperation corresponding to the replication record 70. In the modifyoperation type 74, a string “add” is set when a modify operation is“entry addition”, “delete” is set when “entry deletion”, “modify” is setwhen “entry attribute value change”, and “modrdn” is set when “RDNchange”. The attribute value deletion instruction flag 77, a string “1”or “true” is set when an existing RDN attribute value is deleted at thesame time with “RDN change”, and “0” or “false” is set when an existingRDN attribute value is not deleted at the same time with “RDN change”.

[0164] The change contents 75 exists only when a modify operation is“entry addition” or “entry attribute modify operation”, and the new RDN76, the attribute value deletion instruction flag 77, the new upper RDN78 exist only when a modify operation is “RDN change”.

[0165]FIG. 8 shows the change contents 75 of the replication record 70when a modify operation is “entry attribute modify operation.”

[0166] As shown in FIG. 8, in this case, the change contents 75constitutes a combination of an attribute modify operation type 81 andzero or more than zero of attribute value(s) 83, for each attribute type82, and one or more of the combinations exist. The attribute modifyoperation type 81 indicates the kind of modify operation (“entryattribute modify operation”) corresponding to the replication record 70.The attribute modify operation type 81, a string “add” is set when amodify operation is “attribute value addition”, “delete” is set when“attribute value deletion”, and “replace” is set when “attribute valuechange”.

[0167]FIG. 9 shows the change contents 75 of the replication record 70when a modify operation is “entry add operation”.

[0168] As shown in FIG. 9, in this case, the change contents 75constitutes a combination of an attribute type 91 and attribute value 92owned by an entry to be added, and one or more of the combinationsexist.

[0169]FIG. 12 shows information stored in the replication status file21.

[0170] In FIG. 12, a consumer host name 121 exists for setting a hostname of a directory server on which each consumer directory serverprogram 8 c operates in a case where the replication server program 10performs replication for a plurality of consumer directory serverprograms 8 c, and for identifying a replication status for each consumerdirectory server program 8 c.

[0171] Further, in the time stamp 122 and record number 123, there atime stamp 71 and record number 72 of the latest replication record 70that succeeded in replication are set, indicating up to whichreplication record 70 among replication records stored in thereplication log file 20, replication ended.

[0172] Next, return codes used in LDAP will be described.

[0173] First, FIG. 13 shows LDAP return codes that belong to Group 1.

[0174] A LDAP return code of Group 1 is one returned by the directoryserver program when the same replication request (LDAP access request)is issued a plurality of times.

[0175] This return code varies depending on the kind of the update typeoperation. When an update type operation is “entry addition”, the returncode is “LDAP_ALREADY_EXISTS” indicating that an entry already existshaving the same DN as the DN of the entry of the object of theoperation. In the cases of “entry deletion” and “RDN change”, the returncode is “LDAP_NO_SUCH_OBJECT” indicating that now there is no entryhaving the same DN as the DN of the entry of the object of theoperation. When the update type operation is “entry attribute valueaddition”, the return code is “LDAP_TYPE_OR_VALUE_EXISTS” indicatingthat an attribute value already exists in the attribute type of theobject entry and a plurality of attribute values can not be held, orthat the same attribute value already exists. In a case where the updateoperation is “entry attribute value deletion”, the return code is“LDAP_NO_SUCH_ATTRIBUTE” indicating that now there is no attribute valueof the object entry.

[0176]FIG. 14 shows an LDAP return code that belongs to Group 2.

[0177] The return code of Group 2 is one returned by the directoryserver program when it succeeded in a modify operation in accordancewith the replication request (LDAP access request).

[0178] In the following, a flow of detailed processing of thereplication server program 10 in the first embodiment will be described,referring to FIGS. 15-18.

[0179]FIG. 15 is a flowchart showing a process flow of the replicationserver program 10 in the first embodiment.

[0180] As shown in FIG. 15, the replication server program 10 has apredetermined waiting time, preparing itself for an update in thereplication log file 20 (Step 1502). For example, the waiting time maybe set for 5 seconds.

[0181] When an update in the replication log file 20 can not be detectedwithin the waiting time (Step 1503), it returns to Step 1502 and waitsagain.

[0182] When the replication server program 10 detects an update in thereplication log file 20 within the waiting time (Step 1503), it readsout the host name 61, port number 62, bind method 63, bind DN 64 andpassword 65 from the replication definition file 19 shown in FIG. 6.Then, using the contents read out, the replication server program 10generates a bind request, issues the prepared bind request to theconsumer directory server program 8 c, and receives a response to it(Step 1504).

[0183] Thus, establishing a connection with the consumer directoryserver program 8 c, it then receives an authentication from the consumerdirectory server program 8 c, and starts a session.

[0184] The replication server program 10 then reads out a change logposition 68 from the replication definition file 19 shown in FIG. 6, andacquires a replication record 70 shown in FIG. 7 from the replicationlog file 20 existing at the change log position 68 read out (Step 1505).Step 1505 is processing performed by the change log acquisition program11, and its details will be described below referring to FIG. 16. InStep 1505, one replication record 70 at each time is read out from thereplication log file 20.

[0185] When a replication record 70 to be read out exists, andacquisition of that replication record 70 is successful (Step 1506), thereplication server program 10 generates a replication request based onthe acquired replication record 70 (Step 1508) and issues it to theconsumer directory server program 8 c (Step 1509).

[0186] Successively, the replication server program 10 receives aresponse from the consumer directory server program 8 c, and acquires areturn code included in the received response (Step 1510).

[0187] Then, from the acquired return code, it is judged if thelastReplRecord attribute value was not changed in the last session, andaccordingly the same replication request as one issued in the lastsession has been issued in the current session, resulting in an error.In that case, the return code in question is rewritten as “LDAP_SUCCESS”indicating success of a modify operation according to a replicationrequest, and the error is ignored (Step 1511). Step 1511 is processingperformed by the error judgment program 13, whose details will bedescribed below referring to FIG. 17.

[0188] Then, the replication server program 10 records if the modifyoperation according to the replication request has been successful ornot, into the replication status file 21. Further, in the case ofsuccess, the lastReplRecord attribute value is changed (Step 1512). Step1512 is a processing performed by the replication status recordingprogram 15, whose details will be described below referring to FIG. 18.

[0189] Successively, the replication server program 10 judges if thereturn code (which may be changed in Step 1511) included in the responseto the replication request is “LDAP_SUCCESS” or not (Step 1513). In acase where the return code is “LDAP_SUCCESS”, it generates an unbindrequest, and issues the prepared unbind request to the consumerdirectory server program 8 c (Step 1514).

[0190] Then, when the connection with the consumer directory serverprogram 8 c is released, the replication server program 10 returns toStep 1504, and issues a bind request again to start the next session.

[0191] On the other hand, when the return code is not “LDAP_SUCCESS”,the replication server program 10 ends abnormally (Step 1516). When areplication record 70 to be read out does not exist (Step 1506), thereplication server program 10 issues an unbind request to terminate thesession (Step 1507), and then returns to Step 1502, to wait for anupdate of the replication log file 20, again.

[0192]FIG. 16 shows a flow of the processing performed by the change logacquisition program 11 in Step 1505 of FIG. 15.

[0193] As shown in FIG. 16, the change log acquisition program 11,first, acquires the directory server object DN 67 from the replicationdefinition file 19 shown in FIG. 6 (Step 1601).

[0194] Successively, the change log acquisition program 11 generates alastReplRecord search request for requesting a search of an attributevalue designated by the directory server object DN 67, i.e., thelastReplRecord attribute value indicating the replication recordidentifier 10 c (Step 1602), issues the generated lastReplRecord searchrequest (Step 1603), and receives a response to it (Step 1604).

[0195] Next, it judges if a return code included in the receivedresponse is “LDAP_SUCCESS” or not (Step 1605). When the return code is“LDAP_SUCCESS”, it proceeds to Step 1606, and when the return code isnot “LDAP_SUCCESS”, it proceeds to Step 1608 to end abnormally.

[0196] In Step 1606, the lastReplRecord attribute value 110 shown inFIG. 11 is taken out from the received response, and the time stamp 111and record number 112 are acquired. Then, the replication record 70having a time stamp 71 later than the time stamp 111 included in thelastReplRecord attribute value 110 and a record number 72 greater thanthe record number 112 included in the lastReplRecord attribute value 110is read out from the replication log file 20 (Step 1607), and the changelog acquisition program 11 is ended.

[0197]FIG. 17 shows a flow of the processing performed by the errorjudgment program 13 in Step 1511 of FIG. 15.

[0198] As shown in FIG. 17, the error judgment program 13 first judgeswhether or not the return code included in the response received fromthe consumer directory server program 8 c belongs to the above-describedGroup 1 (Step 1700). When the return code does not belong to Group 1,the error judgment program is ended.

[0199] In a case where the return code belongs to Group 1 (Step 1700),the error judgment program 13 judges it possible that, although thereplication record 70 was correct and both replication server program 10and consumer server program 8 c operate normally, the lastReplRecordattribute value could not be changed in the last session and accordinglythe replication server program 10 issued the same replication requestrepeatedly, and thus caused an error. Accordingly, the error judgmentprogram 13 reads out a time stamp 122 and record number 123 from thereplication status file 21 shown in FIG. 12 (Step 1701).

[0200] Then, it compares the time stamp 71 and record number 72 of thereplication record 70 with the time stamp 122 and record number 123 readout, respectively (Step 1702).

[0201] When, as a result of the comparison of Step 1702, the time stamp71 of the replication record 70 is equal to the time stamp 122, and therecord number 72 of the replication record 70 is equal to the recordnumber 123, it assumes that the same replication request as one issuedin the current session was issued in the last session, and rewrites thereturn code as “LDAP_SUCCESS” (Step 1703) before it ends the errorjudgment program 13.

[0202] When the result of the comparison in Step 1702 is other than theabove-described case, the error judgment program 13 is ended.

[0203]FIG. 18 shows the processing flow performed by the replicationstatus recording program 15 in Step 1512 of FIG. 15.

[0204] As shown in FIG. 18, the replication status recording program 15first judges whether or not a return code included in the responsereceived from the consumer directory server program 8 c belongs to theabove-described Group 2 (step 1801). When the return code does notbelong to Group 2, the replication status recording program 15 is ended.

[0205] When the return code belongs to Group 2 (Step 1801), it is judgedthat the modify operation of the consumer directory server program 8 caccording to the replication request has been successful. It also storesthe time stamp 71 and record number 72 of the replication record 70 intothe time stamp 122 and record number 123 of the replication status file21 shown in FIG. 12, respectively (Step 1802).

[0206] Successively, the replication status recording program 15 readsout the directory server object DN 67 from the replication definitionfile 19. Then, it generates a lastReplRecord update request forrequesting change of an attribute value of an entry designated by thedirectory server object DN 67 read out, i.e., the lastReplRecordattribute value indicating a replication record identifier 10 c (Step1803). Next, it issues the generated lastReplRecord update request (Step1804), and receives a response to it (Step 1805).

[0207] Lastly, the replication status recording program 15 judges if areturn code included in the received response is “LDAP_SUCCESS” or not(Step 1806). When the return code is not “LDAP_SUCCESS”, it endsabnormally (Step 1807). When the return code is “LDAP_SUCCESS”, thereplication state recording program 15 is ended.

[0208] As described above, according to the first embodiment, thereplica data 9 c has, as the directory record identifier 10 c, thelastReplRecord attribute value indicating a replication record forspecifying the entry changed for the last time by the replicationperformed in the last session. Thus, acquiring this lastReplRecordattribute value prior to performing the replication, the replicationserver program 10 can judge which replication record is to be a base forperforming the next replication. Accordingly, by keeping a backup of thereplica data 9 c, even if the replica data 9 s is lost owing to, forexample, physical damage of the magnetic disk 4 c, the second directoryserver 1 c can reconstruct the replica data 9 c using the backup,without acquiring all the entries in the master data 9 s from the firstdirectory server 1 s.

[0209] In the first embodiment, for the second directory server 1 c, amodify operation according to a lastReplRecord attribute value updaterequest can be performed similarly to a modify operation according to areplication request. Further, a search operation according to alastReplRecord attribute search request can be performed as a searchoperation according to a reference type directory access request.Operation of the second directory server 1 c can be similar to theconventional one, when such an entry as one belonging to an object classshown in FIG. 10 and having the lastReplRecord attribute is defined inadvance in the replica data 9 c managed by the second directory server 1c, as an entry for storing a replication record identifier 10 c.

[0210] Next, a second embodiment of the present invention will bedescribed.

[0211] In the conventional technique, when a replication is endedabnormally owing to power supply interruption or the like after issuanceof the replication request and before reception of a response to thatreplication request, the first directory server is performing thereplication can not know if the replication request has been reflectedin the second directory server 1 c or not. Thus, there is such a riskthat, after recovery from the problem, the replication may not berestarted normally. In the first embodiment, a method to resolve such aproblem has not been discussed.

[0212] Namely, in the first embodiment, when a replication is endedabnormally owing to such a problem as power supply interruption afterissuance of the replication request and before reception of a responsefrom the consumer directory server program 8 c, the replication serverprogram 10 can not judge if a modify operation by the consumer directoryserver program 8 c according to the replication request has beensuccessful or not. In that case, it is necessary for the administratorto cause the same replication request as the replication request issuedbefore the abnormal end to be issued again, or to cause a lastReplRecordsearch request to be issued, so as to confirm if the modify operation bythe consumer directory server program 8 c according to the replicationrequest has been successful or not, and then to determine whichreplication record should be the base of the next replication.

[0213] Accordingly, in the second embodiment, it is intended that, evenif the replication is ended abnormally owing to an unexpected problem atany point of time, the replication can be restarted normally afterrecovery from the problem, and thus improve its operability.

[0214] To that end, in the second embodiment, the consumer directoryserver program 8 c has a transaction function, and a modify operationaccording to a replication request and a modify operation according to alastReplRecord update request are processed in the same transaction, soas to assure consistency of the replica data 9 c with the lastReplRecordattribute value.

[0215] In the following, the second embodiment will be described onlywith respect to its difference from the first embodiment.

[0216] A system configuration of a directory system according to thesecond embodiment is similar to the one shown in FIG. 2 with the errorjudgment program 13 being removed. Further, a functional configurationof the replication service according the second embodiment is similar tothe one shown in FIG. 1 with the error judgment part 131 being removed.

[0217] Further, the consumer directory server program 8 c in the secondembodiment has such a transaction function that a series of requestsreceived between a bind request and an unbind request are processed inthe same transaction.

[0218] In detail, in FIG. 4, when change (411) of the lastReplRecordattribute value results in failure, the addition of an entry A (407)performed immediately before is canceled. Further, also in a case wherethe connection is cut off after an entry A (407) is added and beforearrival of an unbind request, the addition of the entry A (407)performed immediately before is canceled.

[0219] Accordingly, always either both the replication request and thelastReplRecord request are reflected or none of them is reflected. As aresult, a lastReplRecord attribute value held by the replica data 9 c asa replication record identifier 10 c is always a correct valueindicating the replication record for specifying the entry changed thereplication for the last time. Accordingly, the error judgment program13 in the first embodiment becomes unnecessary.

[0220] In the following, detailed processing flow by the replicationserver program 10 in the second embodiment will be described referringto FIGS. 19 and 28.

[0221]FIG. 19 is a flowchart showing a flow of processing by thereplication server program 10 in the second embodiment.

[0222] As shown in FIG. 19, the replication server program 10 firstwaits a predetermined waiting time, preparing itself for an update inthe replication log file 20 (Step 1902). For example, the waiting timemay be set for 5 seconds.

[0223] When an update in the replication log file 20 can not be detectedwithin the waiting time (Step 1903), the replication server program 10returns to Step 1902 and waits again.

[0224] When the replication server program 10 detects an update in thereplication log file 20 within the waiting time (Step 1903), it readsout the host name 61, port number 62, bind method 63, bind DN 64 andpassword 65 from the replication definition file 19 shown in FIG. 6.Then, using the contents read out, the replication server program 10generates a bind request, issues the prepared bind request to theconsumer directory server program 8 c, and receives a response to it(Step 1904).

[0225] Thus, establishing a connection with the consumer directoryserver program 8 c, it then receives an authentication from the consumerdirectory server program 8 c, and starts a session.

[0226] Then, the replication server program 10 reads out a change logposition 68 from the replication definition file 19 shown in FIG. 6, andacquires a replication record 70 shown in FIG. 7 from the replicationlog file 20 existing at the change log position 68 read out (Step 1905).Step 1905 is processing performed by the change log acquisition program11, and its details are as described referring to FIG. 16. In Step 1905,one replication record 70 at each time is read out from the replicationlog file 20.

[0227] When the replication record 70 to be read out exists, andacquisition of that replication record 70 is successful (Step 1906), thereplication server program 10 generates a replication request based onthe acquired replication record 70 (Step 1908) and issues it to theconsumer directory server program 8 c (Step 1909).

[0228] Successively, the replication server program 10 receives aresponse from the consumer directory server program 8 c, and acquires areturn code included in the received response (Step 1910).

[0229] Then, the replication server program 10 changes thelastReplRecord attribute value (Step 1912). Step 1912 is processingperformed by the replication status recording program 15, whose detailswill be described below referring to FIG. 28.

[0230] Successively, the replication server program 10 judges if thereturn code included in the response to the replication request is“LDAP_SUCCESS” or not (Step 1913). In a case where the return code is“LDAP_SUCCESS”, it generates an unbind request, and issues the generatedunbind request to the consumer directory server program 8 c (Step 1914).

[0231] Then, when the connection with the consumer directory serverprogram 8 c is released, the replication server program 10 returns toStep 1904, and issues a bind request again to start the next session.

[0232] On the other hand, when the return code is not “LDAP_SUCCESS”,the replication server program 10 ends abnormally (Step 1916). When areplication record 70 to be read out does not exist (Step 1906), thereplication server program 10 issues an unbind request to terminate thesession (Step 1907), and then returns to Step 1902, to re-await anupdate of the replication log file 20.

[0233]FIG. 28 shows a flow of the processing performed by thereplication status recording program 15 in Step 1912 of FIG. 19.

[0234] As shown in FIG. 28, the replication status recording program 15first judges whether or not a return code included in the responsereceived from the consumer directory server program 8 c belongs to theabove-described Group 2 (step 2801). When the return code does notbelong to Group 2, the replication status recording program 15 is ended.

[0235] When the return code belongs to Group 2 (Step 2801), it judgesthat the modify operation of the consumer directory server program 8 caccording to the replication request has been successful. It also readsout the directory server object DN 67 from the replication definitionfile 19. Then, it generates the lastReplRecord update request forrequesting change of an attribute value of an entry designated by thedirectory server object DN 67 read out, i.e., the lastReplRecordattribute value indicating a replication record identifier 10 c (Step2803). Next, it issues the prepared lastReplRecord update request (Step2804), and receives a response to it (Step 2805).

[0236] Lastly, the replication status recording program 15 judges if areturn code included in the received response is “LDAP_SUCCESS” or not(Step 2806). When the return code is not “LDAP_SUCCESS”, it endsabnormally (Step 2807). When the return code is “LDAP_SUCCESS”, thereplication sate recording program 15 is ended.

[0237] As described above, according to the second embodiment, inaddition to the features of the first embodiment, the consumer directoryserver program 8 c has the transaction function, and processes a modifyoperation according to the replication request and a modify operationaccording to the lastReplRecord request in the same transaction. Thus,consistency of the replica data 9 c with the lastReplRecord attributevalue is assured.

[0238] Accordingly, even if the replication ends abnormally owing to anunexpected problem at any point in time, that replication can berestarted after recovery from the problem, thus improving operability.Further, the administrator does not need to be anxious about the extentto which replication has proceeded.

[0239] In the second embodiment, in each session, the replication serverprogram 10 issues a single replication request and a singlelastReplRecord update request, and completes the session. However, it ispossible that, in each session, the replication requests are issued aplurality of times, and the lastReplRecord update request is issuedcorrespondingly to the last replication request. In that case too, thesame effect is obtained in the present invention, since consistency ofthe replica data 9 c with the lastReplRecord attribute value is assuredby the transaction function of the consumer directory server program 8c.

[0240] Next, a third embodiment of the present invention will bedescribed.

[0241] In the first and second embodiments, it is necessary for thereplication server program 10 to issue a lastReplRecord update requestfor requesting a change of the lastReplRecord attribute, in addition toa replication request. Accordingly, network traffic is increased incomparison with the ordinary replication service.

[0242] In the third embodiment, instead of issuing the lastReplRecordupdate request, an extension function of LDAP is used to transmit a newlastReplRecord attribute value to the consumer directory server program8 c, thus suppressing increase of network traffic.

[0243] In the following, the third embodiment will be described onlywith respect to its difference from the first embodiment.

[0244] In the third embodiment, an operation for changing thelastReplRecord attribute value is realized by the extension function ofthe consumer directory server program 8 c. Namely, in the thirdembodiment, the consumer directory server program 8 c has such afunction that, when a Control field of a received replication requestincludes instructions to apply the extension function, the consumerdirectory server program 8 c performs a modify operation of thelastReplRecord attribute value in addition to a modify operation inaccordance with the replication request in question, processing thesetwo modify operations in the same transaction.

[0245]FIG. 27 shows a system configuration of the directory systemaccording to the third embodiment.

[0246] As shown in FIG. 27, the system configuration of the directorysystem according to the third embodiment differs from the systemconfiguration shown in FIG. 2 in that the former does not include theerror judgment program 13, the replication status recording program 15,and the replication status file 21, and includes an extension program 80c performing the extension function for changing the lastReplRecordattribute value.

[0247] The extension program 80 c in the third embodiment is a programconstituting the consumer directory server program 8 c, and is startedup by a value of the Control field included in the replication requestreceived.

[0248]FIG. 26 shows a functional configuration of the replicationservice according to the third embodiment.

[0249] As shown in FIG. 26, the functional configuration of thereplication service according to the third embodiment differs from thefunctional configuration shown in FIG. 1 in that the former does notinclude the error judgment part 13′ and the replication status recordingpart 15′, and includes an extension part 80 c′ as a functional blockrealized by the extension program 80 c shown in FIG. 27.

[0250]FIG. 20 shows a notation of an LDAP access request provided asRFC1777 using ASN.1 provided as ISO8824.

[0251] In this figure, messageID (2001) is a value added to identify anLDAP access request uniquely in one LDAP session. Protocol0p (2002)shows the actual contents of the LDAP access request, and Controls(2003) indicates an extension function applied only to the correspondingLDAP access request.

[0252] A developer of an application can prepare his own extensionfunction within the directory server program in advance, and can useControls (2003) in an LDAP access request to instruct the directoryserver program to apply that extension function.

[0253]FIG. 21 shows a notation of Controls (2003) in accordance withASN.1.

[0254] Controls (2003) consists of a plurality of control fields. As foreach control field, an identifier unique in the world (LDAPOID) is setin controlType (2101), as described in X.208 recommendation of CCITT,for identifying an extension function uniquely, “TRUE” or “FALSE” is setin criticality (2102), and a value used only in the extension functionis set as an octet character string in controlValue (2103).

[0255] When “TRUE” is set in criticality (2102), and the consumerdirectory server program 8 c can not recognize/perform the extensionfunction corresponding to controlType (2103), then the consumerdirectory server program 8 c returns a return code,“unsupportedCriticalExtension” indicating that the extension function isnot supported. When “FALSE” is set in criticality (2102), Controls(2003) is disregarded.

[0256]FIG. 22 shows a notation of the Control field included in areplication request in the third embodiment, in accordance with ASN.1.

[0257] In the third embodiment, Control field instructs application ofan extension function that changes the lastReplRecord attribute value.

[0258] ControlType (2201) is set to an object identifier “<repOid>indicating the extension function, criticality (2202) is set to “TRUE”,and controlValue (2203) is set toa new lastReplRecord attribute value,“<lastReplRecord>”.

[0259]FIG. 23 shows a sequence of the replication service according tothe third embodiment.

[0260] As shown in FIG. 23, the replication server program 10 issues abind request (2301) to the consumer directory server program 8 c, andreceives a response (2302) to that request, so as to establishconnection with the consumer directory server program 8 c.

[0261] Successively, the replication server program 10 issues alastReplRecord search request (2303) to the consumer directory serverprogram 8 c for requesting search of an attribute value oflastReplRecord attribute, and receives a response (2304) including thevalue of lastReplRecord attribute. From the value of the lastReplRecordattribute included in this response (2304), the replication serverprogram 10 can obtain the replication record identifier 10 c in thereplica data 9 c managed by the consumer directory server program 8 c.Thus, the replication server program 10 can know the time stamp andrecord number of the replication record for specifying the entry changedfor the last time by replication performed in the last session.

[0262] Next, the replication server program 10 acquires the time stampand the record number included in the lastReplRecord attribute value forperforming replication in time series for entries on which replicationis not performed. Based on these acquired values, the replication serverprogram 10 performs reading out (2305) of replication records.

[0263] In detail, from the replication log file 20, the replicationserver program 10 reads out the replication record 2314 having the lasttime stamp and smallest record number out of replication records havinga time stamp later than the acquired time stamp “80000000” and a recordnumber greater than the acquired record number “456”.

[0264] Then, based on the replication record 2314 read out, thereplication server program generates a replication request.

[0265] Here, in the third embodiment, LDAP is employed as a protocol,and the generated replication request becomes an LDAP access request.Further, it is assumed here that a modify operation known from thereplication record 2314 is an addition operation of the entry A, andaccordingly, the generated LDAP access request is an entry A additionrequest (2306).

[0266] Successively, the replication server program 10 issues thegenerated entry A addition request (2306) to the consumer directoryserver program 8 c.

[0267] In the third embodiment, for changing the directory recordidentifier 10 c within the replica data 9 c, the replication serverprogram 10 sets the host name of the first directory server is on whichthe supplier directory server program 8 s operates, and the time stampand record number held by the replication record (2311) into the hostname 111, and the time stamp 113 and the record number 112 of thelastReplRecord attribute value 110 shown in FIG. 11, respectively, togenerate a new value of the lastReplRecord attribute. The newlastReplRecord attribute value is set in controlValue of Control fieldwithin an entry A addition request (2306).

[0268] On receiving such an entry A addition request (2306), theconsumer directory server program 8 c performs the addition of the entryA (2307) and a change of the lastReplRecord attribute value (2308) inthe same transaction, and sends a response (2309) indicating theexecution result.

[0269] On receiving the response (2309) from the consumer directoryserver program 8 c, the replication server program 10 issues an unbindrequest (2310) to cut off the connection with the consumer directoryserver program 8 c.

[0270] According to the above-described sequence, the entry A additionoperation performed in the supplier directory server program 8 s ispropagated to the consumer directory server program 8 c. Further, thereplica data 9 c has the new lastReplRecord attribute value indicatingthe replication record for specifying the entry changed for the lasttime by replication, as the replication record identifier 10 c.

[0271] Further, since the entry A addition operation and the modifyoperation of the lastReplRecord attribute value are performed in thesame transaction, consistency of the replica data 9 c with thelastReplRecord attribute value is assured.

[0272] In the following, a flow of processing by the replication serverprogram 10 in the third embodiment will be described in detail referringto FIG. 25.

[0273]FIG. 25 is a flowchart showing a flow of the processing by thereplication server program 10 in the third embodiment.

[0274] As shown in FIG. 25, the replication server program 10 firstwaits a predetermined waiting time, preparing itself for an update inthe replication log file 20 (Step 2502). For example, the waiting timemay be set for 5 seconds.

[0275] When an update in the replication log file 20 can not be detectedwithin the waiting time (Step 2503), it returns to Step 2502 and waitsagain.

[0276] When the replication server program 10 detects an update in thereplication log file 20 within the waiting time (Step 2503), it readsout the host name 61, port number 62, bind method 63, bind DN 64 andpassword 65 from the replication definition file 19 shown in FIG. 6.Then, using the contents read out, the replication server program 10generates a bind request, issues the generated bind request to theconsumer directory server program 8 c, and receives a response to it(Step 2504).

[0277] Thus, establishing a connection with the consumer directoryserver program 8 c, it then receives an authentication from the consumerdirectory server program 8 c, and starts a session.

[0278] Then, the replication server program 10 reads out a change logposition 68 from the replication definition file 19 shown in FIG. 6, andacquires a replication record 70 shown in FIG. 7 from the replicationlog file 20 existing at the change log position 68 read out (Step 2505).Step 2505 is processing performed by the change log acquisition program11, and its details are as described above referring to FIG. 16. In Step2505, at one time, one replication record 70 is read out from thereplication log file 20.

[0279] When the replication record 70 to be read out exists, andacquisition of that replication record 70 is successful (Step 2506), thereplication server program 10 generates a replication request based onthe acquired replication record 70 (Step 2508) and issues it to theconsumer directory server program 8 c (Step 2509). In the thirdembodiment, in Step 2508, the replication server program 10 sets thevalue shown in FIG. 22 into Control field under replication request.

[0280] Successively, the replication server program 10 receives aresponse from the consumer directory server program 8 c, and acquires areturn code included in the received response (Step 2510).

[0281] Then, the replication server program 10 judges if the receivedreturn code is “LDAP_SUCCESS” or not (Step 2511). When the return codeis “LDAP_SUCCESS”, it generates an unbind request, and issues thegenerated unbind request to the consumer directory server program 8 c(Step 2512).

[0282] Then, when the connection with the consumer directory serverprogram 8 c is released, the replication server program 10 returns toStep 2504, and issues a bind request again to start the next session.

[0283] On the other hand, when the return code is not “LDAP_SUCCESS”,the replication server program 10 ends abnormally (Step 2513). When thereplication record 70 to be read out does not exist (Step 2506), thereplication server program 10 issues an unbind request to terminate thesession (Step 2507), and then returns to Step 2502, to wait again for anupdate of the replication log file 20.

[0284]FIG. 24 shows a partial flowchart from receipt of a replicationrequest to return of response in the consumer directory server program 8c, for explaining an extension function in the third embodiment.

[0285] As shown in FIG. 24, on receiving a replication request, theconsumer directory server program 8 c analyzes this replication request(Step 2401).

[0286] Successively, the consumer directory server program 8 c issues anupdate request based on the contents of the request to a databasemanaging the replica data 9 c so as to change the replica data 9 c (Step2402). Then, it judges if the modify operation is successful or not(Step 2403). In the case of failure, it returns an error response (Step2409).

[0287] Further, in a case where the modify operation is successful (Step2403), the consumer directory server program 8 c confirms, as for thereceived replication request, if a value of controlType has the Controlfield which is an identifier indicating an extension function (Step2404).

[0288] When the value of controlType does not have Control field as anidentifier indicating an extension function, it proceeds to Step 2407.When the value of controlType has Control field as an identifierindicating an extension function, it changes the lastReplRecordattribute value expressing the replication record identifier 10 c to thevalue of controlValue (Step 2405).

[0289] Further, when the modify operation is successful (Step 2406), theconsumer directory server program 8 c issues, to the database, a Commitrequest for effectuating all the modify operations performed up to thatpoint in time and terminating the transaction (Step 2407). Lastly, ittransmits a response indicating success (Step 2408), and ends theprocessing for the replication request received.

[0290] In a case where the modify operation ends in failure (Step 2406),it issues a Rollback request for nullifying all the modify operationsperformed up to that point of time and terminating the transaction (Step2410), cancels the received replication request, and transmits an errorresponse (Step 2411).

[0291] As described above, according to the third embodiment, inaddition to the features of the first and second embodiments, thereplication server program 10 uses Controls as an extension function ofLDAP to add instructions to change the lastReplRecord attribute value toeach replication request. Accordingly, it is not necessary to issue alastReplRecord update request for requesting a change of thelastReplRecord attribute, in addition to a replication request, and anincrease of network traffic is suppressed.

[0292] As described above, according to the present invention,information to specify the entry changed by the replication for the lasttime is recorded in the replica data managed by a directory server onthe consumer side. Thus, based on this information, a server performingreplication can know an entry on which the next replication is to beperformed, and accordingly, can recognize the difference between themaster data managed by the directory server on the supplier side and thereplica data managed by the directory server on the consumer side.

[0293] Thus, by keeping a backup of the replica data, even if thereplica data has been lost owing to, for example, physical damage to arecording medium, the directory server on the consumer side canreconstruct the replica data using the backup, without acquiring all theentries in the master data from the directory server on the supplierside, thus improving operability.

[0294] Further, according to the present invention, in the directoryserver on the consumer side, a program managing the replica data has atransaction function. Using this transaction function, an entry modifyoperation and a modify operation on information indicating that entryare processed in the same transaction. Accordingly, consistency of thereplica data with information for specifying an entry changed for thelast time in the replica data is assured.

[0295] Thus, even if the replication ends abnormally owing to unexpectedproblem at any point in time, it is possible to restart the replicationnormally after the recovery from the problem, which improvesoperability. Further, the administrator needs not worry about the extentto which the replication proceeded, which reduces the burden on theadministrator.

What is claimed is:
 1. A replication method for keeping contents ofmaster data and contents of replica data in a directory system, inwhich, a first directory server manages the master data of directorydata and records and holds replication log of operations in changingsaid master data; one or more second directory servers each manages itsreplica data as a replica of said master data; and said first directoryserver and said one or more second directory servers are connected atleast through a network; wherein one (hereinafter, referred to as“replication server”) of said first directory server and another serverconnected to said network: acquires a replication log which becomes anobject of processing out of the replication log recorded and held by thesaid first directory server; issues a directory access request(hereinafter, referred to as “replication request”) that requestsperforming, on said replica data, the same operations as operationscorresponding to the acquired history operation to said second directoryserver; records an identifying information for specifying thereplication log corresponding to said operations performed by saidsecond directory server, into the replica data managed by said seconddirectory server, when said operation performed in accordance with saidreplication request is successful, and refers to the identifyinginformation recorded in the replica data managed by said seconddirectory server to decide replication log to be acquired, in acquiringreplication log which is to be an object of processing out of thereplication log recorded and held by said first directory server.
 2. Thereplication method according to claim 1, wherein said replication serverissues a directory access request that requests performing an operationof searching said identifying information, to said second directoryserver, so as to refer to the identifying information recorded in thereplica data managed by said second directory server.
 3. The replicationmethod according to claim 2, wherein: said replication server issues adirectory access request that requests performing an operation ofrecording said identifying information, to said second directory server,so as to record said identifying information into the replica datamanaged by said second directory server.
 4. The replication methodaccording to claim 3, wherein: even when the operations performed bysaid second directory server in accordance with said replication requestresult in failure, said replication server judges the failure as successif the failure is caused by issuing the same replication request as thereplication request successively more than once, and the second serverspreviously received the same replication request as the replicationrequest.
 5. The replication method according to claim 2, wherein: saidsecond directory server performs a predefined specific operation inaccordance with contents set into a predefined specific field within adirectory access request received; and said replication server sets,into said specific field of said replication request, informationnecessary for said second directory server to perform a specificoperation of recording said identifying information, so that saididentifying information is recorded into the replica data managed bysaid second directory server.
 6. The replication method according toclaim 5, wherein: said second directory server performs an operationaccording to said replication request and an operation of recording saididentifying information, in the same single transaction.
 7. Thereplication method according to claim 6, wherein: said first directoryserver and said second directory server belong to one object class, andmanage respectively entries constituting said master data and saidreplica data, as objects, each having one or more attributes; and saididentifying information belongs to a specific object class defined inadvance, and recorded into an entry managed as an object having aspecific attribute defined in advance, as an attribute value of saidspecific attribute.